第6章 ユーザーストーリーを集める
6.1 文書化の難しさ
多大な時間を消費して管理しているドキュメントは、大概無駄になることがある。
顧客要望に応えれるものになってなかったり、エンジニアのとっても求められるものは構築できない
結果、何を文書に書くべきかだけの議論に時間が費やされる
またドキュメントは言葉の文脈で違う意味で捉えれることがあるので、文書に頼りすぎるのもよくない
アジャイル開発の原則
情報を伝えるもっとも効率的で効果的な方法はフェイストゥフェイスで話をすること
要件定義書の要件にかかれているもので、ビジネスの利益の影響するのは5% ~ 20%と言われる。つまり、それ以外は必要条件・必須な要件ではない
この本当の要求を引き出したりする方法がユーザーストーリである
6.2 そこでユーザーストーリですよ
ユーザーストーリーとは顧客がソフトウェアで解決したいと思っていることを簡潔にに記述したもの
ポイントは簡潔にとうところで、詳細なとこまでは聞かない。詳細まで詰めたところで、実装するのに何ヶ月もかかって、その頃にはユーザーストーリーが変わることもある。
必要になったタイミングで詳細を検討するフェーズにはいる
アジャイル開発ではユーザーストーリーはインデックスカードに記載する。以下のようなイメージ
https://scrapbox.io/files/67f673e48432b2ba972994f1.png
6.3 よく書けているユーザーストーリー
顧客が対価を払ってもいいと思える価値があるか
顧客がわからない技術用語を使って記述をしない
顧客がわかる言葉づかいを意識することが大事
Ex: データベースにコネクションプールを導入する → 現在の10秒かかるページの読み込み速度を2秒まで縮める
可能な限り独立してフィーチャー単位で記述する
スコープを柔軟にできたり、機能同士のトレードオフの判断をさけることもできる
交渉の余地がある
予算の範囲内に収まるように、ある程度の融通に効くようになるため
機能のテストがある
Ex:通常のログインができる・期限切れのログインはリダイレクトする・適切なエラーメッセージを表示する
1週間から2週間で達成できるストーリで小さく見積もる
上記の要素（独立している・交渉の余地がある・価値のある・見積もれる・小さい・テストできる）はビル・ウェイクの考案。頭文字をとってINVESTと呼ぶ 要件定義書とユーザーストーリーの違いは以下
https://scrapbox.io/files/67f679f0dd0965ff5ca282bd.png
インデックスカードを書き込んだら、テンプレートに沿ってユーザーストーリーを記載する
誰の：ためのストーリーで
何を：したいのか
なぜ：そうしたいのか
実際の例
https://scrapbox.io/files/67f67f5e90597ab8095a0221.png
6.4 ストーリー収集ワークショップを開催しよう
ストーリー収集ワークショップとはソフトウェアで実現したいことを、開発チーム・顧客が一丸になってワークすること
ステップ１：大きくて見通しのよい部屋を用意する
大きい部屋を準備して、カードを並べられるようにする
ステップ２：図をたくさん書く
ペルソナやフローチャートなど図を使って書いていく
大事なことは詳細には記載しないこと
ステップ３：ユーザーストーリーをたくさんかく
ステップ２で作成して図を用いて、ユーザーストーリーを記載する
粒度は小さく、具体的で、エンドツーエンドの機能にすることを心がける
大きなストーリーのなる場合はこれをエピックと呼ぶ
10 ~ 40ぐらい書き出せれば、3 ~ 6ヶ月の計画は立てられる。
ステップ４：その他もろもろブレインストーミング
フィーチャーに関連するストーリーと同じく記述すること（データ移行・負荷テスト・手順書作成など）
上記のストーリーも優先順位つけておくこと
インセプションデッキの「ご近所さん」を探せがここで活きてくる。ステークホルダーのことも考慮しておくことができる
ステップ５：リストを磨き上げる
最初のマスターストーリーリストが作成できたら時間をとって、だぶりや漏れがないか、グループ化できていないかを確認する
ストーリーの一覧は顧客にもわかるTODOになっているかを確認する